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ABSTRACT 

While the Cassini spacecraft telemetry design 
had taken on the new approach of "packetized 
telemetry”, the AACS (Attitude and Articulation 
Subsystem) had further extended into the design 
of "mini-packets" in its telemetry system. Such 
telemetry packet and mini-packet design 
produced the AACS Telemetry Dictionary, 
iterations of the latter in turn provided changes to 
the former. The ultimate goals were to achieve 
maximum telemetry packing density, optimize 
the "freshness" of more time-critical data, and to 
effectuate flexibility, i.e. multiple AACS data 
collection schemes without needing to change 
the overall spacecraft telemetry mode. This 
paper describes such a systematic process and 
methodology, evidenced by various design 
products related to, or as part of, the AACS 
Telemetry Dictionary. 


INTRODUCTION 

An efficient ground data system and effective 
telemetry data processing / analysis system stem 
from good engineering design with respect to 
timeliness, frequency, accuracy, and sufficiency 
of the data contents in the telemetry stream. The 
human interaction with the data, thence 
consumption of the data, can also be enhanced 
by human-engineered telemetry displays and 
systematic organization of the telemetry 
measurements. 

Such objectives can be achieved, in part, by an 
up front design of a flexible and efficient 
telemetry handling system on board the 
spacecraft, and of an equally efficient ground 
data analysis system. A common thread between 
the flight and ground systems is the Telemetry 
Dictionary. 

In the present context, the Telemetry Dictionary 
is more than just a collection of telemetry 


measurements with their descriptions, arranged 
in some alphabetical ordering. The development 
process of the Dictionary is intertwined and 
iterative with the design process of the telemetry 
system. In fact, the Dictionary is not simply the 
child-of-the-parent of the telemetry design; it is 
also the parent-of-the-child. The Dictionary 
evolves from the telemetry design process; and 
through iterations, the Dictionary development in 
turn provides improvement and optimization to 
the telemetry design. 

This iterative process was particularly necessary 
for the Cassini AACS (Attitude and Articulation 
Subsystem) because of its new approach of using 
a "packetized telemetry" system versus the 
widely used "time division multiplex" (TDM) 
system. The AACS further extended the packet 
design to include the "mini-packet" design. 

The ultimate goals of the mini-packet and packet 
telemetry design were to achieve maximum 
telemetry packing density, optimize the 
"freshness" of more time-critical data, and to 
effectuate flexibility, i.e. multiple AACS data 
collection schemes without needing to change 
the overall spacecraft telemetry mode. 

The Cassini AACS telemetry design also 
responded to the object-oriented design approach 
of the AACS flight software. The fundamental 
entity of telemetry collection was to be based on 
each software object. A bottoms-up approach 
was used to assemble and analyze the telemetry 
measurements per software object. A database 
was constructed in which each measurement (i.e. 
record) was associated with attributes including 
measurement-number (E-numbers in Cassini), 
mini-packet, software object, channel 1 type, bit 
assignment, scale factor etc. 


"Channels" are herein used synonomously with telemetry 
"measurements", and should not be confused with 
"telecommunication channel, bandwidth". 
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Through iterative analysis, the collection of 
measurements was screened, organized, and 
assigned to the fundamental unit of a telemetry 
mini-packet. Mini-packets were created that 
grouped measurements by similar functions 
and/or similar collection periods. A systematic 
optimization of mini-packet assignments led to 
the consolidation of the database, from which 
statistics were synthesized and analyzed. AACS 
telemetry modes were designed corresponding to 
the overall spacecraft telemetry modes - a virtue 
of the flexibility of a mini-packet packetized 
telemetry system. Telemetry maps specifying 
the periodicity of telemetry mini-packets were 
designed, satisfying overall spacecraft telemetry 
bandwidth allocation requirements. 

This paper describes such a systematic process 
and methodology, evidenced by various design 
products related to, or as part of, the AACS 
Telemetry Dictionary. This work was performed 
during the first part of Fiscal Year 1994, and was 
completed before the AACS Flight Software 
Critical Design Review. 


FEATURES OF A TELEMETRY 
DICTIONARY 

References to the AACS Telemetry Dictionary 
of Galileo (ref. 1), Mars Observer (ref. 2), and 
Cassini (ref. 3) reveal the common features of a 
telemetry dictionary of a major-size spacecraft. 
Putting aside those spacecraft-specific design 
features that should always be documented, the 
following list shows the major features to be 
included in the telemetry dictionary: 

- Spacecraft telemetry system description 

- Subsystem (e.g. AACS) telemetry system 
desciption 

- Telemetry design: data acquisition, process- 
ing, storing, and transmission; telemetry 
maps, rates, modes (overall spacecraft mode 
versus subsystem mode) 

- Telemetry detailed design: data format, 

headers, trailers, fillers, engineering "transfer 
frames", major frames 

- Telemetry packets, mini-packets 

- Special telemetry modes 

- Telemetry Indices: by channel number, 
display mnemonics, data type, subsystem 
association, flight software name, and 
frequency (periodicity) 

- Telemetry data sheet (by channel number) 


- Telemetry subcommutation map (for TDM) 
design; packet and mini-packet tables (for 
"packetized" design) 

- Telemetry modes, transitions, relationship 
between spacecraft mode and subsystem 
(telemetry / operation) mode 

- Parent-to-child relationship between channels 
(child-channels are usually derived in Ground 
Data System in order to relieve spacecraft 
downlink burden) 

Spreadsheet or database documentation of 
channel data is ideal not only for sorting / 
indexing purposes, but also invaluable in the 
analysis / synthesis of telemetry modes, rate 
(periodicity) association, decommutation and 
mini-packet / packet design. Spreadsheet 
columns, i.e. attributes, should at least include 
channel number, display mnemonics, data type, 
subsystem association, flight software name, and 
frequency (periodicity). 

In fact, the basis of the Cassini AACS Telemetry 
Dictionary used for the mini-packet / packet 
design, rate group association, and overall 
downlink channel bandwidth optimization, was a 
spreadsheet documentation of all telemetry 
channels. 

Additional attributes included in the Cassini 
AACS Telemetry Dictionary spreadsheets were 
associations to software object, hardware unit, 
and mini-packet function (hence mini-packet 
name). Desired data frequency (periodicity) was 
a very important attribute, used in the iterative 
design of the mini-packets. The desired 
periodicity expressed the "freshness" 
requirement, and was represented by cardinal 
ratings of F, FM, M, MS, and S (i.e. fast, fast- 
medium, medium, medium-slow, and slow). 
Attributes of data types (signed integer, unsigned 
integer, floating-point, digital, state and ASCII) 
and number of data bits were included for 
channel bandwidth optimization and statistics 
summarization. 


PACKET / MINI-PACKET DESIGN vs 
TDM (Time Division Multiplex) DESIGN 

The gist of the design differences between 
packet / mini-packet design versus TDM design 
is the absence vs presence of a "telemetry 
decommutation map". 
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In a TDM design, a channel will be included in 
the telemetry stream (regardless of whether the 
stream is to be downlinked or stored on-board) at 
a fixed location according to the decommutation 
map. A map covers all locations of a complete 
unit of telemetry stream (also known in Galileo 
as Major Frame, in Mars Observer as 
Engineering Transfer Frame). At a given bit 
rate, the "frame" always spans the same duration 
of time. (Hence, the scheme is called TDM.) 

Within a decommutation map, the same channel 
can appear once or multiple times. In the former 
case, the channel is said to be in the "slow deck"; 
in the latter, "medium" or "fast" deck, depending 
on the repetition rate. In Galileo, there are 
basically three rates, the "ninety-one-deck", 
"thirteen-deck", and "zero-deck", ranging from 
slow to fast. For 1200 bps telemetry rate, the 
periods are 60 2/3 sec., 8 2/3 sec, and 2/3 sec. In 
Mars Observer, in the 2000 bps Engineering 
Mode, there are the 32 sec., 8 sec., 1 sec. "- 
decks" for the flight computer processed data. 

Decommutation maps are large. There can be 
multiple maps, one for each Spacecraft "mission" 
mode. In Mars Observer, there are four modes: 
Engineering, Mission, Emergency and Safe 
Mode; with different bit rates ranging from fast 
to slow, respectively. In Galileo, even though bit 
rate can change from 1200 bps down to 8 bps, 
the same decommutation map still applies; 
however, there is an extra "Variable Telemetry 
Map" that can be selected from four choices. All 
Variable Telemetry Maps provide 22.5 (16-bit) 
words, equivalently 18 plus 9 one-half channels 
at the zero-deck rate. 

Changes to decommutation maps are possible 
normally via memory loads at specific memory 
addresses. Such a change process is labor- 
intensive. 

For Cassini, if TDM were used, the maps would 
be even larger (about five times as large as 
Galileo, and one-and-a-half times larger than 
Mars Observer). This is not simply due to 
complexity of the spacecraft, i.e. number of 
subsystems, but is due to increase of compuation 
power of the on-board computers. 

Without using the packet / mini-packet design, 
Cassini would suffer excessive sluggishness in 
AACS telemetry - where the fastest allocation 


downlink rate was at 1896 bps, with 576 bps 
allocated to AACS. 

The mini-packet design provides AACS with 
total freedom to assign desired / appropriate 
mini-packets to the fixed packet size allocated to 
AACS. Each Spacecraft Subsystem is allocated 
a certain packet size. Multiple (not necessarily 
integral number of) packets can be included in an 
"engineering transfer frame". 

Flexibility is achieved by associating AACS 
Telemetry Modes for certain AACS Operation 
Modes, and against all Spacecraft Mode. Instead 
of having the TDM decommutation map(s), 
maps of telemetry channels in mini-packets 
(regardless of modes), and maps of mini-packets 
in packets (per AACS Telemetry Mode) are 
stored. The first set of maps are much smaller 
than a TDM decommutation map. The second 
set of maps are basically tables of "(m,n) 
frequency" allocation of mini-packets to packets. 

"(m,n)" frequency in Cassini means that, for that 
AACS Telemetry Mode, m mini-packets will be 
contained in n packets. E.g. (8,1) is the fastest 
rate and (1,64) is the slowest rate in Cassini. At 
an AACS packet period of 8 sec., they represent 
mini-packet periods of 1 sec and 512 sec. 

For more details on TDM, mini-packets, 
guaranteed delivery of mini-packets in packets, 
see (ref. 1-4) 


CASSINI PROCESS & METHODOLOGY 
of Telemetry Dictionary Development 

The Cassini AACS telemetry design and 
Telemetry Dictionary development was an 
interactive and iterative process. Using project 
organization terminology, it was a cooperative 
task performed between the AACS Subsystem 
Group, Control Analysis Group, Flight Software 
Group, Hardware & Electronics Group, and the 
Ground Data Systems / Mission Operations 
Group. 

While generic telemetry channel requirements 
were synthesized by the Subsystem Group, 
specific candidates were proposed by the 
Hardware Group, Analysis Group, and the 
Software Group. Inheritance from the Galileo 
and Mars Observer designs was duly observed. 
In fact, a one-to-one comparison was made 
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between the Galileo AACS Telemetry 
Dictionary and the candidate Cassini Dictionary, 
revealing potential omissions and confirming 
completeness. 

From the respective AACS Groups, requirements 
for candidate telemetry channel, periodicity, data 
bits (resolution, precision), and format were 
drawn on hardware (sensors, actuators, 
hardware-to-electronics interfaces); control 
states, intermediate and observable variables; 
flight computer hardware data, hardware 
configuration and overall fault protection data. 
The Ground System Group was consulted 
regarding mission operations requirements and 
channel bandwidth optimization. Human 
engineered mnemonics and channel type 
assignment were prescribed to all measurements 
conforming with JPL's AMMOS (Advanced 
Multi-Mission Operations System) ground 
software standards. 

The object-oriented software design of the 
AACS flight software design (some 20 objects) 
(ref. 5) provided an easy association of telemetry 
to software objects. The list of object names and 
their statistics are given in Table 1. (The 
Telemetry Manager is one such object.) Table 2 
is a sample of this initial compilation of 
telemetry dictionary, for the Software Object of 
"Accelerometer_Telemetry_Manager". Since 
object-oriented software design has distinct input 
output data flow, the same telemetry can be 
tapped from either the source or destination. A 
rule of thumb was adopted to tap the telemetry 
from the source, unless certain functional 
groupings made it more desirable to tap from the 
destination. 

A spreadsheet for all telemetry channels was 
then composed, where all attributes were 
entered, including their cardinal ordering of 
periodicity. 

At that point, mini-packets were designed which 
attempted to group telemetry by 

- functionality 

- similarity in periodicity requirement 

- manageable size of mini-packet. 

The number of mini-packets were kept to a 
minimum, compromising with the uniformity 
(diversity) of the functionality and periodicity of 
the channels grouped within the same mini- 
packet. 


The mini-packet attribute was then added to the 
spreadsheet. With each iteration, new packet / 
mini-packet design was synthesized and their 
statistics analyzed. Iterations on the spreadsheet, 
good engineering practice, and negotiations with 
the engineer(s) requiring the specific channels 
(and other requirements), then led to a 
compromised mini-packet design. 

While the design work was approaching 
completion, bandwidth allocation had yet to be 
analyzed. This was when the cardinal ordering 
of mini-packet periodicity was translated into 
ordinal (m,n) association. 

New spreadsheets were prepared (Table 3), 
which were linked to the Telemetry Dictionary 
spreadsheet, linked for channel attributes such as 
data bit size and mini-packet association. An 
iterative analysis and synthesis further led to 
optimized (m,n) periodicity associations, 
addition/deletion/merging of mini-packets, and 
final assignment of channels to mini-packets. 

Finally, an overall design of AACS Telemetry 
Modes, corresponding to all AACS Operation 
Modes and Spacecraft "Mission" Modes led to 
more rounds of iterations and finalization of the 
telemetry design, mini-packet / packet design, 
and, above all, the AACS Telemetry Dictionary. 

Samples of the Final Dictionary (as of Jan., 94) 
are given in Table 4 and 5, where the telemetry 
channels are ordered by channel-numbers (i.e. 
E-numbers", also by Software Objects), and by 
mini-packets. 

All in all, 1088 channels in 67 mini-packets were 
assembled in the AACS Telemetry Dictionary. 
Out of these 67 mini-packets, 6 contained the 
less used off-diagonal covariance and Kalman 
gain elements (161 measurements), which are 
non-essential during normal mission operations. 
Eliminating those left 947 measurements in 61 
mini-packets. A total of seven telemetry maps 
corresponding to 7 AACS telemetry modes were 
constructed. These modes are: (1) Record; (2) 
Nominal Cruise; (3) Medium Slow Cruise; (4) 
Slow Cruise; (5) Orbital Ops; (6) Av; (7) ATE 
(Attitude Estimator) Calibration. These 7 maps 
cover all spacecraft telemetry modes. For further 
information about mode transitions, and for 
details of the AACS Telemetry Dictionary, refer 
to (ref. 3 and 6.) 
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CONCLUSION 

The process of bottoms-up development, use of 
human engineering skills, and the construction of 
the database had permitted a systematic way of 
sorting, synthesizing and analyzing all Cassini 
AACS telemetry measurements. Maximizing the 
use of database formulas and linking databases 
also permitted expedient parametric variation 
and analysis of bottom-line figures; examples of 
the latter were dictionary statistics, and 
bandwidth consumption (vs allocation) for 
specific telemetry modes. Hence, an effective 
and flexible packet / mini-packet design scheme. 

This process of developing the packet / mini- 
packet design and the establishment of the 
AACS Telemetry Dictionary had proven to be 
closely intertwined and cross-productive. The 
end result also provided the design for the 
"Telemetry Manager" flight software object. 
The process helped to bind a contract, i.e. 
interface specification of telemetry measurement 
between software objects. It further provided 
important feedback to software control algorithm 
designers for finalizing design parameters. 

In conclusion, not only was this Cassini process 
a means to an end - the Telemetry Dictionary, it 
was also a team -player in the overall AACS 
flight software design. 
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Software 

ACL 


TABLE 1. Summary Statistics 
Object 


- # of Channels vs Software Obiect 

J t i i - f ■ 


Hdwe ass’n 


# channels 


Notes 


ACM 
ADC 
ATE 
CFG 
CMD 
CMT 
FPA 
FPR 
FSX 
IOUmgr 
I VP 
MOD 
PROM 
SID 
TLM 
XBA 
ACC 
EGA 
IRU 
PMS 
RWA 
SRU 
SSA 


Attitude Control 

Attitude Commander 

Attitude Determinat'n Commander 

Attitude Estimator 

Configuration Manager 

Command Manager 

Constraint Manager 

Fault Protection & Analyzer 

Fault Protection Recovery 

Flight Software Executive 

Input_Output_Unit Manager 

Inertial Vector Propagator 

Mode Commander 

PROM_Control 

Star ID (identification) 

Telemetry Manager 
Cross-string Bus Adapter 
Accelerometer Manager 
Engine Gimbal Actuator 
Inertial Reference Unit 
Propulsion Module System 
Reaction Wheel Assembly 
Stellar Reference Unit 
Sun Sensor Assembly 


Software 

29 


Software 

43 


Software 

1 


Software 

244 

161 cov & Knot essential 

XXX 

124 


Software 

15 


Software 

13 


XXX 

280 

24 assigned; 256 TBD 

Software 

3 


EFC 

71 


XXX 

54 


Software 

1 


Software 

5 


Software 

6 


Software 

64 


Software 

2 


Software 

24 


HdweJMgr 

7 


HdweMgr 

10 


Hdwe_Mgr 

12 


HdweJVlgr 

10 


Hdwe_Mgr 

48 

TOTAL # ch.'s = 1094 

Hdwe_Mgr 

18 

less non-ess. ATE = 933 ] 

Hdwe_Mgr 

10 

less TBD FPA ch = 677 j 
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Tabl e 2 . 


Telemetry List for Accelerometer_Manager Software Object 


Ch# 

(new#) 


Mnemonics 


Mini 

Pkt# 


Attribute 

prime 


Hardware 
associat ' n 


Software Rate] 
object cruise* 


Type Bit Scale 
Factor 


E 1001 ACC state 

E 1002 ACC_calBIAS 

E 1003 deltaV_ACC 

E 1004 ACC_totBIAS 

E 1005 deltaV_tmtg 

E 1006 ACC_.tmtg 

E 1007 raw_ACC_CT 


4 

21 

21 

21 

21 

21 

22 


Sfwe_State2 

deltaV 

deltaV 

deltaV 

deltaV 

deltaV 

IRU/ACC_data 


ACC 

ACC 

ACC 

ACC 

ACC 

ACC 

ACC 


HdweMgr 

HdweMgr 

HdweMgr 

HdweMgr 

HdweMgr 

HdweMgr 

HdweMgr 


M 

Z 

Z 

MS 

Z 

Z 

MS 


"driftDelta'' - calib prior to deltaV 
''deltaV" - after scale factor compensatic 
"drift"= driftNominal+driftDelta 
"deltaVTimeTag " , used to compute "diffTin 
"timeTag" ; 8 + 8 bits 

"accumDeltaV" - before scale factor compe 


4 

16 

16 

16 

16 

16 

16 


Legend: Rate (cruiseF = fast; M = medium; S= slow; FM = medium fast; MS = medium slow: 2 = zero, except in special 


mode 


E 

1394 

ACC_cycle 

26 

IRU/ACC_stat 

ACC 

CFG 

S 




E 

1395 

ACC_ONtime 

26 

IRU/ACC_stat 

ACC 

CFG 

S 

unit in second 


8 

E 

1650 

ACC_RESETct 

37 

Reset_count 

ACC 

IOU mgr 

S : 




E 

1665 

ACC_ERR 

38 

Bus_error 

ACC 

IOU mgr 

S 




E 

1666 

ACC_ERR_ct 

38 

Bus_error 

ACC 

IOU mgr 

S 




E 

2035 

ACC_val_ERR 

46 

Anomaly_st2 

ACC 

FPA 

MS 

ACC_mgr : "accTooBigFault " 



E 

203 6 

ACC_drf_ERR 

46 

Anomaly_st2 

ACC 

FPA 

MS 

ACC_mgr : “dri f tTooBigFaul t “ 

D 

4 


Table 4. AACS 


Telemetry Dictionary - sorted by Channel# and Software object {page 1 of XX) 


ch# 

(new#) 


Mini Attribute Hardware Software Rate] 
Pkt# prime aasociat'n object jruise* 


Type Bit Scale 
Factor 


E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

I E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 


1001 

1002 

1003 

1004 

1005 

1006 
1007 

1021 

1022 

1023 

1024 

1025 

1026 

1027 

1028 

1029 

1030 

1031 

1032 

1033 

1034 

1035 

1036 

1037 

1038 

1039 

1040 

1041 

1042 

1043 

1044 

1045 

1046 

1047 

1048 

1049 


ACC state 

ACC_calBIAS 

deltaV_ACC 

ACC_totBIAS 

deltaV_tmtg 

ACC_tmtg 

raw_ACC_CT 


momUNLOADst 

MANUVR_st 

ATT_CNTR_st 

POSdadBND_X 

POSdadBND_Y 

POSdadBND_Z 

RATEddBND_X 

RATEddBND_Y 

RATEddBND_Z 

ddBND_IbitX 

ddBND_Ibi tY 

ddBND_IbitZ 

P0Serr_X 

POSerr_Y 

POSerr_Z 

RATErr_X 

RATErr_Y 

RATErr_Z 

cmdTORQUE_X 

cmdTORQUE_Y 

cmdTORQUE_Z 

cmd_S/C_H_X 

cmd_S/C_H_Y 

cmd_S/C_H_Z 

cmd_thrustX 

cmd_thrustY 

cmd_thrustz 

BURN_time 

deltaV_pred 


1061 TURN_status 

1062 ATT_CMD_st 

1063 cmdSC_Ql 
etc etc 


4 

21 

21 

21 

21 

21 

22 

3 

3 

4 

6 

6 

6 

6 

6 

6 

6 

6 

6 


11 

11 

11 

11 

11 

11 

21 

21 

21 

21 

21 


Sfwe_State2 

ACC 

HdweMgr 

M 

deltaV 

ACC 

HdweMgr 

Z 

deltaV 

ACC 

HdweMgr 

Z 

deltaV 

ACC 

HdweMgr 

Z 

deltaV 

ACC 

HdweMgr 

z 

deltaV 

ACC 

HdweMgr 

z 

IRU/ACC_data 

ACC 

HdweMgr 

MS 

Sfwe_State 

Sfwe 

ACL 

FM 

Sfwe_State 

Sfwe 

ACL 

FM 

Sfwe_State2 

Sfwe 

ACL 

M 

SC_pointg2 

Sfwe 

ACL 

S 

SC_pointg2 

Sfwe 

ACL 

S 

SC_pointg2 

Sfwe 

ACL 

S 

SC_pointg2 

Sfwe 

ACL 

S 

SC_pointg2 

Sfwe 

ACL 

s 

SC_pointg2 

Sfwe 

ACL 

s 

SC_pointg2 

Sfwe 

ACL 

s 

SC_pointg2 

Sfwe 

ACL 

s 

SC_pointg2 

Sfwe 

ACL 

s 

Att_cntrl 

Sfwe 

ACL 

FM 

Att_cntrl 

Sfwe 

ACL 

FM 

Att_cntrl 

Sfwe 

ACL 

FM 

Att_cntrl 

Sfwe 

ACL 

FM 

Att_cntrl 

Sfwe 

ACL 

FM 


Att_cntrl 
RWA cntrl 
RWA cntrl 
RWA cntrl 
RWA cntrl 
RWA cntrl 
RWA cntrl 
deltaV 
deltaV 
deltaV 
deltaV 
deltaV 


3 Sfwe_State 

4 Sfwe_State2 

5 SC_pointing 

etc etc. 


Sfwe 

Sfwe 

Sfwe 

Sfwe 

Sfwe 

Sfwe 

Sfwe 

Sfwe 

Sfwe 

Sfwe 

Sfwe 

Sfwe 

Sfwe 
Sfwe 
Sfwe 
etc . 


ACL 

ACL 

ACL 

ACL 

ACL 

ACL 

ACL 

ACL 

ACL 

ACL 

ACL 

ACL 

ACM 
ACM 
ACM 
etc . 


lACC_mgr : "driftDelta" - calib prior to de 
Mgr : ’deltaV" - after scale factor cc 

ACC_mgr : "drift"= driftNominal+driftDelta 
|ACC_mgr : "deltaVTimeTag", used to compute 
;ACC_mgr: "timeTag"; 12+8 bits 
[ACC_Mgr: "accumDeltaV" - before scale fac 

RCS/ACL : “ inact i ve/THRUSTR_WARMUP/UNloadi 
[T VC/ RCS_del t aV / ACL : "off /TVC_enab 1 ed/ RCS 


RCS/ACL : changes by +/-20% during cruise; 
RCS/ACL: changes by +/-20% during cruise; 
RCS/ACL: changes by +/-2Q% during cruise; 

I RCS/ACL: constants 
RCS/ACL: constants 
RCS/ACL: constants 

|RCS/ ACL : impulse bang-bang ctrl S/C att c 
RCS/ACL: impulse bang-bang Ctrl S /C att c 
RCS/ACL: impulse bang-bang Ctrl S/C att c 
FM ISame measurement for RCS,RWA,TVC. RCS: de 
Same measurement for RCS,RWA,TVC. RCS: de 
Same measurement for RCS,RWA,TVC. RCS: de 
Same measurement for RCS/RWA/TVC. RCS: de 
ditto [IRU res of 0 . 25Hrad/pulse/0 . 25 sec 
ditto (IRU res of 0 . 25nrad/pulse/0 . 25 sec 
RWA/ ACL : Different f orm RWA_TQ ' s . Here 
'RWA/ACL: Different form RWA_TQ's. Here 
I RWA/ ACL : Different form RWA_TQ’s. Here 
I RWA /ACL : Different from ATE's momemntum 
RWA/ACL: Different from ATE’s momemntum 
RWA/ACL : Different from ATE's momemntum 
JTVC/ACL: "TsubC " 
jTVC/ACL : "TsubC" 

ITVC/ACL: "TsubC" 

16 + 8 bits. 0.004 sec res 2 / '16 = 65536 sec 
[TVC/ACL: predict of the time profile of 1 


FM 

M 

MS 

etc. 


Completed/Rate_Matching/ POS_matching/COA 


"base_attitude' 
letc . 


S 

I 

I 

I 

u 

u 

I 

s 

s 

s 

u 

u 

u 

u 

u 

u 

u 

u 

u 

I 

I 

I 

I 

1 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

u 

u 

s 

S 

I 


2 

1 

16 

5.0 E6 

20 

500 

16 

5.0 E6 

20 

BITcrop 

20 

BITcrop 

24 

1 

2 

1 

2 

1 

4 

1 

16 

1.0 E5 

16 

1.0 E5 

16 

1.0 E5 

16 

1.0 E6 

16 

1.0 E6 

16 

1.0 E6 

16 

TBD 

16 

TBD 

16 

TBD 

16 

2.0 E5 

16 

2.0 E5 

16 

2. 0 E5 

16 

1.0 E6 

16 

1 . 0 E6 

16 

1.0 E6 

16 

2.0 E5 

16 

2.0 E5 

16 

2.0 E5 

16 

1.0 E3 

16 

1.0 E3 

16 

1.0 E3 

16 

TBD 

16 

TBD 

16 

TBD 

24 

BITcrop 

20 

500 

2 

1 

4 

1 

16 

32768 

etc 

etc 
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Table 5. AACS Telemetry Dictionary - sorted by Mini_Packet# (page 1 of XX) 


Ch Ch# Mnemonics Mini Attribute Hardware Software Rate | 
(new#) Pkttt prime associat'n object cruise* 


Motes 


Type Bit 


Scale 
Factor I 


E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 

E 


1121 

1122 

1123 

1124 

1125 

1126 

1381 

1382 

1383 

1384 

1385 

1386 

1387 

1388 

1389 

1390 

1391 

1392 

1393 

1021 

1022 

1061 

1127 

1541 

1741 

1742 

1743 


B0DY_Z_RA 

BODY_Z_DEC 

BODY_Z_TWIS 

X_rate 

Y_rate 

Z_rate 

BUS_pr ime 

SNSR_pwr 

ACTR_pwr 

SNSR_pr ime 

ACTR_prime 

SNSR^hlth 

ACTR_hlth 

VDE_pwr 

VDE_pr ime 

VDE_hlth 

RCS__pr ime 

RCS_A_hlth 

RCS_B_hlth 

momUNLOADst 

MANUVR_st 

TURN_status 

SunEphm_chk 

CMT_status 

AACS_mode 

AACS_statl 

AACS_stat 2 


1023 

1062 

1111 

1128 

1129 

1542 

1543 
1001 

1561 

1562 

1711 

1712 

1713 

1714 

1761 

1762 

1791 

1792 

1793 

1794 

1931 

1932 

1961 

1962 

1963 

1964 
1731 
1851 

1981 

1982 


E 1063 
E 1064 
E 1065 
E 1066 
E etc . 


ATT_CNTR_st 

ATT_CM D_st 

ADC_state 

ATT_EST_st 

deltaV_ESst 

AVOID_state 

PTGviolatST 

ACC state 

EGAA_state 

EGAB_state 

IRUA_state 

I RUB_state 

I RUA_status 

IRUB_status 

PMSA_state 

PMSB_state 

RWAl_state 

RWA2_state 

RWA3_state 

RWA4_state 

SRUA__state 

SRUB_state 

SSAA_state 

SSAB_state 

SSAA_status 

SSAB_status 

IVP_status 

SID_state 

AACStlmMode 

Set lm_mode 

cmdSC_Ql 
cmdSC_Q2 
cmdSC_Q3 
cmdSC_Q4 
etc . 


1 

Est_Att 

Sfwe 

ATE 

F 

20 bit: 6 jirad resolution 

1 

Est_Att 

Sfwe 

ATE 

F 

i 20 bit: 6 (frad resolution 

1 

Est_Att 

Sfwe 

ATE 

F 

20 bit: 6 ffrad resolution 

1 

Est_Att 

Sfwe 

ATE 

F 


1 

Est_Att 

Sfwe 

ATE 

F 


1 

1 

Est_Att 

Sfwe 

ATE 

F 


2 

Hdwe_con£ ig 

EFC 

CFG 

M 


2 

Hdwe_conf ig 

Hdwe 

CFG 

M 


2 

Hdwe_conf ig 

Hdwe 

CFG 

M 


2 

Hdwe_conf ig 

Hdwe 

CFG 

M 


2 

Hdwe_conf ig 

Hdwe 

CFG 

M 


2 

Hdwe_conf ig 

Hdwe 

CFG 

M 


2 

Hdwe_conf ig 

Hdwe 

CFG 

M 


2 

Hdwe_conf ig 

PMS 

CFG 

M 


2 

Hdwe_conf ig 

PMS 

CFG 

M 


2 

Hdwe_conf ig 

PMS 

CFG 

M 


2 

Hdwe__conf ig 

PMS 

CFG 

M 


2 

Hdwe_conf ig 

PMS 

CFG 

M 


2 

2 

Hdwe_conf ig 

PMS 

CFG 

M 


3 

Sfwe_State 

Sfwe 

ACL 

FM 

RCS/ACL : ’’ inactive/THRUSTR WARMUP/UNloadi 


Sfwe_State 

S fwe 

ACL 

FM 

TVC/RCS_deltaV/ACL : “off/TVC enabled/RCS 

3 

Sfwe_State 

Sfwe 

ACM 

FM 

"Completed/Rate_Matching/POS matching/COA 

3 

Sfwe_State 

Sfwe 

ATE 

FM 

SSA sun_vect not equal (with tolerance) t 

3 

Sfwe_State 

Sfwe 

CMT 

FM 

" Nominal/noJ 2000 /withJ 2000 /t imeout " 

3 

Sfwe_State 

Sfwe 

MOD 

FM 


3 

Sfwe_State 

Sfwe 

MOD 

FM 


3 

3 

Sfwe_State 

S fwe 

MOD 

FM 


4 

Sfwe_State2 

Sfwe 

ACL 

M 


4 

Sfwe_State2 

Sfwe 

ACM 

M 


4 

Sfwe_State2 

Sfwe 

ADC 

M 


4 

Sf we_State2 

Sfwe 

ATE 

M 


4 

Sfwe_State2 

Sfwe 

ATE 

M 

T >'C/RCS_delta_V/ACL: " idle/acc/timer/impt 

4 

Sfwe_State2 

Sfwe 

CMT 

M 

''Celest ial_vect/body vect “ 

4 

Sfwe_State2 

Sfwe 

CMT 

M 

body_jvec t / therma 1 violation duration" 

4 

Sfwe_State2 

ACC 

HdweMgr 

M 


4 

S f we_State2 

EGA 

HdweMgr 

M 


4 

Sfwe_state2 

EGA 

HdweMgr 

M 


4 

Sfwe_State2 

IRU 

HdweMgr 

M 

" on/of f * 

4 

Sfwe_State2 

IRU 

HdweMgr 

M 

" on /of f " 

4 

Sfwe_State2 

IRU 

HdweMgr 

M i 

"max_pulse_viol ;max acc viol;A&B consiste 

4 

Sfwe_State2 

IRU 

HdweMgr 

M 

"max_pulse_viol;max acc viol;A&B consiste 

4 

Sfwe_State2 

PMS 

HdweMgr 

M 

"on/off ; idle;ME_critical enabled; ME pulse 

4 

Sfwe_State2 

PMS 

HdweMgr 

M 

'on/ off; idle;ME_critical enabled; ME_pulse 

4 

Sfwe_State2 

RWA 

HdweMgr 

M 


4 

Sfwe_State2 

RWA 

HdweMgr 

M 


4 

Sfwe_State2 

RWA 

HdweMgr 

M 


4 

Sfwe_State2 

RWA 

HdweMgr 

M 


4 

Sfwe_State2 

SRU 

HdweMgr 

M 


4 

S fwe_State2 

SRU 

HdweMgr 

M 


4 

Sfwe_State2 

SSA 

HdweMgr 

M 

on/off " 

4 

Sfwe_State2 

SSA 

HdweMgr 

M 

on/off " 

4 

Sfwe_State2 

SSA 

HdweMgr 

M 

auto/grd_cmd ' d thrshid;sun there;sun ste 

4 

Sf we_State2 

SSA 

HdweMgr 

M 

auto/ grd_cmd 1 d thrshld;sun there; sun sta 

4 

Sfwe_State2 

Sfwe 

IVP 

M a 

la GLL IVP Stat 

4 

Sfwe_State2 

Sfwe 

SID 

M s 

tates in transition diagram 

4 

Sfwe_State2 

Sfwe 

TLM 

M 


4 

4 

Sfwe_State2 

Sfwe 

TLM 

M 


5 

SC_pointing 

S fwe 

ACM 

MS ; ' 

base_att itude " 

5 

SC_point ing 

Sfwe 

ACM 

MS " 

base_attitude " 

5 

SC_pointing 

Sfwe 

ACM 

MS " 

base attitude" 

5 

SC_pointing 

Sfwe 

ACM 

MS " 

base attitude" 

tc . 

etc . 

etc. 

etc . 

etc. 

etc. et 


20 

2^19/jt 

20 

2^19/k 

20 

2^19/k 

16 

2. 0 E5 

16 

2.0 E5 

16 

2.0 E5 

16 

1 

8 

1 


32768 

32768 

32768 

32768 

etc 


232 


